It has been obvious for a while that PowerShell 2 was going to be strongly supported as the natural scripting language for Windows Server 2008 R2 and Windows 7. It comes with interesting new features, such as the ability to execute scripts on remote systems and write native “ScriptCmdlets”. What’s more it now has a very nice IDE, and the various administrative GUIs in Windows Server will now generate PowerShell scripts that can be saved for reuse. It seems certain that PowerShell will be on all the servers in your organisation and that all administrative scripting is going to be in PowerShell. If you are a system or database administrator, you are just going to have to grit your teeth and get started on one of the 400-page books that introduce the tool.

Were it not for the fact that PowerShell is as intuitive as Linear B, it would be game over. As it is, IronPython and IronRuby remain interesting alternatives. They make the scripting process far simpler, and the syntax is much closer to the type of programming language that DBAs are used to. They become even more attractive when one considers the versatility of the .NET Dynamic Language Runtime (DLR), which allows you to plug IronPython or IronRuby into your .NET applications, call C# methods and so on. Maybe, with these DLR-based languages, we really are moving closer to achieving the dream of all DBAs: one scripting language to do everything. However, your Sysamin will loathe them as he will be engrossed in the extended culture-shock of having to redo all his favourite scripts in PowerShell.

Sadly, there have been losers as well as winners in the scripting wars. Jscript.net, which briefly appeared in Silverlight, seems to have quit this mortal coil, doomed by the emergence of the DLR, which was more likely to deliver a fast-performing script. Perl too doesn’t seem to have made the leap into the .NET environment.

Does any of this matter? Does a DBA even need scripting languages? Many DBAs out there still perform maintenance tasks by hand, server-by-server, database-by-database, occasionally reaching for SQLCMD and SQL Agent. Or perhaps, at most, using a few VBScript /DMO solutions that they haven’t quite got round to updating for SMO.

Is this an unfair representation of DBAs attitude to scripting? Is it time to redo all those old scripts in PowerShell, or are there viable alternatives? We’d love to hear from you.

Cheers,

Tony.